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Abstract 

By  shifting  the  burden  of  proofs  to  the  user,  a  proof-carrying  authorization  (PCA)  system 
can  automatically  enforce  complex  access  control  policies.  Unfortunately,  managing  those 
proofs  can  be  a  daunting  task  for  the  user.  In  this  paper  we  develop  a  Bash-like  language, 
PCAL,  that  can  automate  correct  and  efficient  use  of  a  PCA  interface.  Given  a  PCAL 
script,  the  PCAL  compiler  tries  to  statically  construct  the  proofs  required  for  executing 
the  commands  in  the  script,  while  re-using  proofs  to  the  extent  possible  and  rewriting  the 
script  to  construct  the  remaining  proofs  dynamically.  We  obtain  a  formal  guarantee  that 
if  the  policy  does  not  change  between  compile  time  and  run  time,  then  the  compiled  script 
cannot  fail  due  to  access  checks  at  run  time. 


1  Introduction 


Proof-carrying  authorization  (PCA)  [3,5,6,18,20,22]  is  a  modern  access  control  technology, 
where  an  access  control  policy  is  formalized  as  a  set  of  logical  formulas,  and  a  principal  is 
allowed  to  perform  an  operation  on  a  resource  only  if  that  principal  can  produce  a  proof 
showing  that  the  policy  entails  that  the  principal  may  perform  the  operation  on  the  resource. 
While  this  architecture  allows  automatic  enforcement  of  complex  access  control  policies,  it 
substantially  increases  the  burden  of  the  user,  since  each  request  to  perform  an  operation 
must  be  accompanied  by  one  or  more  proofs.  Furthermore,  even  if  the  user  employs  a 
theorem  prover  to  construct  the  proofs,  the  user  must  still  ensure  that  enough  proofs  are 
generated  for  each  request  to  succeed,  while  minimizing  the  costs  of  proof  construction 
at  run  time.  In  this  paper  we  develop  a  programming  language  that  can  assist  the  user 
in  performing  such  tasks  correctly  and  automatically  in  a  system  with  PCA.  We  have 
implemented  a  compiler  for  our  language  and  tested  it  with  a  PCA-based  file  system, 
PCFS  [18]. 

Our  language,  PCAL,  extends  the  Bash  scripting  language  with  some  PCA-specific 
annotations;  the  PCAL  compiler  translates  programs  with  these  annotations  to  ordinary 
Bash  scripts,  to  be  executed  in  a  system  with  PCA.  More  precisely,  PCAL  annotations  can 
specify  what  proofs  the  programmer  expects  to  hold  at  particular  program  points.  Based 
on  these  annotations,  the  compiler  performs  the  following  tasks. 

1.  It  checks  that  the  programmer’s  expectations  about  proofs  suffice  to  allow  successful 
execution  of  every  shell  command  in  the  script.  For  this,  the  compiler  needs  to 
know  what  permissions  are  required  to  execute  each  shell  command.  We  provide  this 
information  through  a  configuration  file. 

2.  Next,  the  compiler  uses  a  theorem  prover  and  information  about  the  access  control 
policy  to  try  to  statically  construct  proofs  corresponding  to  the  programmer’s  anno¬ 
tations.  In  cases  where  static  proof  construction  fails,  because  the  annotations  do  not 
convey  enough  static  information,  the  compiler  generates  code  that  constructs  the 
proof  at  run  time  by  calling  the  theorem  prover  from  the  command  line. 

3.  Finally,  the  compiler  adds  code  to  pass  appropriate  proofs  for  each  shell  command  to 
the  PCA  interface. 

Thus,  the  output  of  the  compiler  is  a  Bash  script  which,  beyond  the  usual  commands, 
contains  some  code  to  generate  proofs  at  run  time  (when  it  cannot  generate  such  proofs  at 
compile  time),  and  some  code  to  pass  the  proofs,  generated  either  statically  or  dynamically, 
to  the  PCA  interface. 

Using  PCAL  offers  at  least  two  advantages  over  a  naive  approach,  where  a  user  generates 
and  passes  to  the  PCA  interface  enough  proofs  of  access  before  running  an  unannotated 
script. 

1.  Because  of  the  static  checks  and  dynamic  code  generated  by  the  compiler,  it  is  guar¬ 
anteed  that  the  resulting  script  will  at  least  try  to  construct  all  necessary  proofs  of 
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access.  Thus,  the  script  can  fail  only  if  the  user  does  not  have  enough  privileges  to 
run  it,  and  not  because  the  user  forgot  to  create  some  proofs.  Indeed,  we  formally 
prove  that  if  compilation  of  a  program  succeeds  and  the  policy  does  not  change  be¬ 
tween  compilation  and  program  execution,  then  the  program  cannot  fail  due  to  an 
access  check  (Theorem  4.2).  This  is  very  significant  for  scripts  where  the  user  cannot 
determine  a  priori  what  operations  the  script  will  perform. 

2.  Since  the  compiler  sees  all  commands  that  the  script  will  execute,  it  re-uses  proofs  to 
the  extent  possible  and  reduces  the  proof  construction  overhead,  which  a  naive  user 
may  not  be  able  to  do.  This  is  particularly  relevant  for  PO SIX- like  policies  where 
accessing  a  file  requires  an  “execute”  permission  on  all  its  ancestor  directories.  If 
several  files  in  a  directory  need  to  be  processed,  there  is  no  need  to  construct  proofs 
for  the  ancestor  directories  again  and  again.  The  PCAL  compiler  takes  advantage  of 
this  and  other  similar  structure  in  policies  and  combines  it  with  information  about  a 
program’s  commands  to  minimize  proof  construction. 

By  design,  PCAL  and  its  compiler  are  largely  independent  of  the  logic  used  to  express 
policies.  The  compiler  requires  a  theorem  prover  compatible  with  the  logic  used,  but  it  does 
not  analyze  formulas  or  proofs  itself.  Thus,  the  compiler  can  be  (trivially)  modified  to  use 
a  different  logic.  Similarly,  the  compiler  is  parametric  in  the  shell  commands  it  supports. 
It  assumes  a  map  from  each  shell  command  to  the  permissions  needed  to  execute  it,  and 
a  single  command  to  pass  proofs  to  the  PCA  interface.  By  replacing  this  map  and  the 
command,  the  compiler  can  be  used  to  support  any  PCA  interface,  not  necessarily  a  file 
system. 

PCAL  is  distinct  from  other  work  that  combines  PCA  with  a  programming  language  [4, 
20] .  In  all  such  prior  work,  the  language  is  used  to  enforce  access  control  statically.  On  the 
other  hand,  PCAL  uses  a  combination  of  static  checks  and  dynamic  code  to  ensure  compli¬ 
ance  with  the  requirements  of  the  PCA  interface.  Static  enforcement  is  a  special  case  of  this 
approach,  where  an  input  program  is  rejected  unless  the  compiler  can  construct  all  required 
proofs  at  compile  time.  Furthermore,  in  all  prior  work  proofs  are  data  or  type  structures 
and  programmers  must  write  explicit  code  to  construct  them.  In  particular,  programmers 
must  understand  the  logic.  In  contrast,  PCAL  separates  proofs  from  programs,  and  shifts 
the  burden  of  constructing  proofs  (and  understanding  the  logic)  from  programmers  to  an 
automatic  theorem  prover.  We  believe  that  this  not  only  makes  PCAL’s  design  modular, 
but  also  easier  to  use. 

Contributions 

We  believe  that  we  are  the  first  to  propose,  design,  and  implement  a  language  that  uses 
a  combination  of  static  checks  and  dynamic  code  to  optimize  the  proof  burden  of  a  PCA- 
compliant  program.  This  setting  presents  some  unique  technical  challenges,  and  our  design 
and  implementation  require  some  novel  elements  to  deal  with  those  challenges. 

1.  While  we  would  like  to  discharge  as  many  proofs  as  possible  statically,  we  must  be 
concerned  about  possibly  invalidating  the  assumptions  underlying  those  proofs  at  run 
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time.  For  instance,  the  state  of  the  system  may  not  remain  invariant  between  compile 
time  and  run  time.  This  requires  a  careful  separation  of  (dynamic)  state  conditions 
from  other  (static)  policies. 

2.  Since  the  values  of  some  program  variables  cannot  be  determined  at  compile  time,  the 
PCAL  compiler  constructs  quantified  proofs  which  are  parametric  over  these  program 
variables.  These  variables  are  substituted  at  run  time  to  obtain  ground  proofs.  (See 
Section  5  for  details.) 

3.  Programmer  annotations  in  PCAL  have  both  static  and  dynamic  semantics.  Stati¬ 
cally,  they  specify  authorization  conditions  and  other  constraints  that  should  hold  at 
run  time,  thereby  aiding  verification  of  correctness  by  the  compiler.  Dynamically,  they 
verify  any  assumptions  on  the  existence  of  authorization  proofs  and  other  constraints 
made  by  the  compiler,  thereby  allowing  sound  optimizations. 

4.  For  practical  reasons,  we  must  also  be  concerned  about  balancing  the  relative  strengths 
and  weaknesses  of  a  theorem  prover  (to  discharge  proofs)  and  compiler  (to  analyze 
programs).  We  achieve  such  a  balance  by  working  at  several  levels  of  abstraction. 
While  all  functions  and  predicates  used  in  a  script  have  concrete  implementations  at 
run  time,  the  compiler  only  partially  interprets  these  functions  and  predicates  with 
abstract  rewrite  rules,  so  that  the  program  can  be  analyzed  with  appropriate  precision 
by  symbolic  techniques.  Furthermore,  calls  to  the  theorem  prover  are  simplified,  so 
that  the  theorem  prover  can  treat  all  functions  and  predicates  as  uninterpreted,  and 
thus  can  search  for  proofs  efficiently.  Tying  these  levels  of  abstraction  together  requires 
some  care  in  the  implementation.  This  is  discussed  further  in  Section  5. 

5.  We  prove  formally  that  the  behavior  of  a  compiled  program  is  the  same  as  that  of  the 
source  program  (Theorem  4.1)  and  that  successfully  compiled  programs  cannot  fail 
due  to  access  checks  (Theorem  4.2).  The  proofs  of  these  theorems  require  a  precise 
characterization  of  assumptions  on  the  theorem  prover,  the  proof  verifier,  and  the 
relation  between  the  environment  in  which  the  program  is  compiled  and  that  in  which 
it  is  executed.  We  believe  that  this  characterization  is  a  significant  contribution  of 
this  work,  because  it  is  fundamental  to  any  architecture  that  uses  a  similar  approach. 

The  rest  of  the  paper  is  organized  as  follows.  After  closing  this  section  with  a  brief 
review  of  related  work,  in  Section  2  we  discuss  some  background  material  covering  PCA, 
and  the  assumptions  we  make  about  the  interface  it  provides.  Section  3  introduces  PCAL 
and  its  compiler  through  an  example.  Details  of  the  language,  its  compilation,  and  correct¬ 
ness  theorems  are  covered  in  Section  4.  Some  important  implementation-related  issues  are 
discussed  in  Section  5. 

Related  Work 

There  are  two  prior  lines  of  work  on  combining  proofs  of  authorization  with  languages.  The 
first  line  of  work  includes  the  languages  Aura  [20,24]  and  PCML5  [4],  where  PCA  as  well 
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as  a  logic  for  expressing  policies  are  embedded  in  the  type  system,  and  proofs  are  data 
or  type  structures  that  programs  can  analyze.  This  contrasts  with  PCAL,  where  proofs 
cannot  be  analyzed.  PCAL’s  approach  is  advantageous  because  it  decouples  the  logic  from 
the  language,  thus  making  it  easy  to  use  the  same  compiler  with  different  logics.  It  also 
alleviates  the  programmer’s  burden  of  understanding  the  logic.  On  the  other  hand,  in  Aura 
and  PCML5,  parts  of  proofs  can  be  re-used  in  different  places,  thus  allowing  potentially  more 
efficient  proof  construction  than  in  PCAL.  However,  it  is  unclear  whether  this  advantage 
extends  when  automatic  theorem  provers  are  used  in  either  Aura  or  PCML5. 

The  second  line  of  work  includes  several  languages  that  culminate  in  the  most  recent 
F7  [8, 14].  These  languages  use  an  external  logic  like  PCAL,  but  the  objective  is  to  express 
logical  conditions.  The  programmer  can  introduce  logical  assumptions  at  different  program 
points,  and  check  statically  at  other  program  points  that  those  assumptions  entail  some 
other  formula(s).  In  PCAL  it  is  not  necessary  that  each  programmer  annotation  about  a 
proof  succeed  statically;  if  it  fails,  code  to  construct  the  proof  at  run  time  is  automatically 
inserted.  This  approach  is  similar  to  hybrid  typechecking  [13],  especially  as  applied  to  recent 
security  type  systems  [9, 11].  Indeed,  PCAL  departs  from  previous  lines  of  work  in  that  it 
does  not  try  to  enforce  security  on  its  own;  instead  it  is  meant  as  a  tool  to  help  programs 
comply  with  a  PC  A  interface  that  enforces  security. 

PCA,  the  architecture  that  PCAL  supports,  was  introduced  by  Appel  and  Felten  [3]. 
It  has  been  applied  in  different  settings  including  authorization  for  web  services  [5],  the 
Grey  system  [6],  and  the  file  system  PCFS  [18].  The  latter  implementation  is  the  basic  test 
bench  for  PCAL.  The  specific  logic  used  for  writing  policies  in  this  paper  (and  PCFS)  is 
BL  [15, 16].  It  is  related  to,  but  more  expressive  than,  many  other  logics  and  languages  for 
writing  access  policies  (e.g.,  [1,2,7,12,17,19,23]). 

2  Background 

In  this  section  we  provide  a  brief  overview  of  PCA,  and  list  particular  assumptions  that 
PCAL  makes  about  the  underlying  PCA-based  system  interface. 

PCA  [3,5,6,18,20,22]  is  a  general  architecture  for  enforcing  access  control  in  settings 
that  require  complex,  rule-based  policies.  Policy  rules  are  expressed  as  formulas  in  some 
fixed  logic,  and  enforced  automatically  using  formal  proofs.  Let  C  denote  a  set  of  formulas 
that  represent  the  access  policy  (see  Section  3  for  an  example) .  The  system  interface  grants 
user  A  permission  77  (e.g.,  read,  write)  on  a  resource  t  (e.g.,  a  file)  only  if  A  produces 
a  formal  proof  7  which  shows  that  £  entails  a  formula  auth(A,  77,  t )  in  the  logic’s  proof 
system.  The  formula  auth(A,  77,  t)  means  that  A  has  permission  rj  on  resource  t.  Its  exact 
form  depends  on  the  logic  in  use  and  the  resources  being  protected,  but  is  irrelevant  for  the 
purposes  of  this  paper.  (Here  it  suffices  to  assume  that  auth(A,  77,  t)  is  an  atomic  formula.) 
The  system  interface  checks  the  proof  that  A  provides  to  make  sure  that  it  uses  the  logic’s 
inference  rules  correctly,  and  that  it  proves  the  intended  formula.  The  system  interface 
must  provide  a  mechanism  by  which  users  can  submit  proofs  either  prior  to  or  along  with 
an  access  request.  Even  though  users  are  free  to  construct  proofs  by  any  means  they  like, 
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it  is  convenient  to  have  an  automatic  theorem  prover  to  perform  this  task. 

Assumptions 

PCAL’s  compiler  supports  rich  logics  for  writing  policies,  in  which  proofs  may  depend  not 
only  on  the  formulas  constituting  the  policy,  but  also  on  system  state  (e.g.,  nreta-data  of 
files  and  clock  time).  Let  H  denote  the  system  state.  We  write  7  ::  H\  C  b  s  to  mean  that 
7  is  a  formal  proof  which  shows  that  in  the  system  state  H ,  policies  C  entail  formula  s.  (In 
particular,  s  may  be  auth(A,  77,  t).) 

PCAL  assumes  that  an  automatic  theorem  prover  for  the  logic  is  available,  both  through 
an  API  and  as  a  command  line  tool.  A  call  to  the  theorem  prover  (either  through  the  API 
or  the  command  line)  is  formally  summarized  by  the  notation  H;  C  b  s  \  7,  which  means 
that  asking  the  theorem  prover  to  construct  a  proof  for  s  from  policy  C  in  state  H  results 
in  the  proof  7.  Dually,  H;C  h  s  X,  means  that  the  theorem  prover  fails  to  construct  a 
corresponding  proof.  The  latter  does  not  imply  the  absence  of  a  proof  in  the  logic,  since  the 
theorem  prover  may  implement  an  incomplete  search  procedure.  The  following  command  is 
assumed  to  invoke  the  prover  from  the  command  line  and  store  in  the  file  pf  a  proof  which 
establishes  auth(A,r/,t)  from  the  policies  in  /pi  and  the  prevailing  system  state. 

prove  auth(A,  77,  t)  /pi  >  pf 

For  passing  proofs  to  the  system  interface,  we  assume  a  simple  protocol:  a  command  inject 
is  called  from  the  command  line  to  give  a  proof  to  the  system  interface,  which  puts  it  in  a 
store  that  is  indexed  by  the  triple  ( A ,  7,  t)  authorized  by  the  proof.  During  the  invocation 
of  a  system  API,  relevant  proofs  are  retrieved  from  this  store  and  checked.  For  example, 
the  following  command  injects  the  proof  in  the  file  pf  into  the  interface’s  store. 

inject  pf 

While  proofs  required  to  execute  commands  at  run  time  must  be  ground,  proofs  produced 
at  compile  time  may  contain  free  variables,  which  we  assume  are  listed  in  order,  and  which 
need  to  be  instantiated  at  run  time.  For  such  proofs,  the  run-time  substitutions  of  such 
variables  are  also  provided  to  the  inject  command  (with  option  -subst),  so  that  the 
injected  proofs  are  always  ground.  For  example,  the  following  command  substitutes  the 
run-time  values  of  some  Bash  variables  (in  order)  for  the  free  variables  in  the  proof  read 
from  file  .  pf  and  stores  the  resulting  proof  in  the  system  interface. 

inject  pf  -subst  $_PRIN  $z  $x  $y  $bar  $foo 


3  Overview  of  PCAL 

In  this  section,  we  work  through  a  small  example  to  demonstrate  the  steps  of  our  com¬ 
pilation.  (PCAL  is  formalized  in  Section  4.)  For  this  example,  let  there  be  a  predicate 
extension  and  functions  path  and  base,  such  that  (informally): 
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•  extension(/,  e)  holds  if  file  /  has  extension  e; 

•  path(d,  x)  =  p  if  path  p  is  the  concatenation  of  directory  d  and  name  x; 

•  base(p)  =  x  if  path(d,  x)  =  p  for  some  directory  d. 

Consider  the  program  P  in  Figure  1,  written  in  PCAL.  This  program  iterates  through 
the  files  in  some  directory  f  oo  (unspecified),  copying  them  to  a  directory  bar  (set  to  "/tmp"). 
Furthermore,  it  touches  those  files  in  f  oo  that  have  extension  "log".  The  reader  may  ignore 
the  assert  statements  (in  lines  2,  8,  12,  and  13)  in  a  first  reading;  we  explain  their  meaning 
below. 

The  system  is  configured  to  check,  for  any  command,  that  certain  permissions  are  held  on 
certain  paths  in  order  to  execute  that  command.  Let  us  assume  the  following  configuration: 

Configuration 


•  Iterating  over  directory  d  requires  permission  read  on  d. 

•  Executing  the  shell  command  touch (/)  requires  permission  write  on  file  /. 

•  Executing  the  shell  command  cp(/i,/2)  requires  permission  read  on  file  f\,  and  per¬ 
mission  write  on  file  f-2 . 

I _ I 


The  assert  statements  in  P  serve  to  establish,  at  run  time,  that  the  principal  running 
the  script  has  particular  permissions  on  particular  paths.  The  compiler  tries  to  statically 
identify  assert  statements  that  must  succeed  at  run  time,  and  eliminate  them  at  compile 
time. 

Assume  that  member  is  a  predicate  such  that  member  (/,  d)  holds  if  file  /  is  in  direc¬ 
tory  d.  Consider  the  following  policy,  written  in  a  first-order  logic  with  the  convention  that 
implication  is  right  associative. 

Policy 

I - 1 

auth("User",  read,  "/home"). 

VA.Vx.  auth(A,  write, path("/tmp"  ,  x)). 

VA.Vx.Vy.  member(x,  y)  auth(A,  read,  y) 

(auth(A,  read,  x)  A 

(extension(x ,  "log")  auth(A,  write,  x))). 

I _ I 

Informally,  the  policy  asserts  the  following: 

•  the  principal  "User"  has  permission  read  on  directory  "/home" 

•  any  principal  A  has  permission  write  on  any  file  in  the  directory  "/tmp" 
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Program  P  Program  Q 


1 

bar 

=  "/tmp"; 

1 

bar 

=  "/tmp"; 

2 

assert  (read,  foo) ; 

2 

assert  (read,  foo) ; 

3 

for 

x  in  foo  { 

3 

for 

x  in  foo  { 

4 

y  =  x; 

4 

y  =  x; 

5 

x  =  base (x) ; 

5 

x  =  base (x) ; 

6 

z  =  path(f oo ,  x) ; 

6 

z  =  path(f oo ,  x) ; 

7 

test  extension(z,  "log")  { 

7 

test  extension(z,  "log 

8 

assert  (write,  z) ; 

8 

—  assert  (write, 

9 

shell  touch(z) 

9 

shell  touch(z) 

10 

>; 

10 

>; 

11 

z  =  path (bar,  x) ; 

11 

z  =  path (bar,  x) ; 

12 

assert  (write,  z) ; 

12 

—  assert  (write,  z) ; 

13 

assert  (read,  y) ; 

13 

—  assert  (read,  y) ; 

14 

shell  cp(y,  z) 

14 

shell  cp(y,  z) 

15 

> 

15 

> 

Script  S 

! /bin/bash 

function  base  {  _RET=${1##*/}  } 
function  path  {  _RET=$l/$2  } 

function  extension  {  if  [  =  $2  ] ;  then  _RET="ok";  fi  } 

_PRIN="User" 
f oo="/home" 

1  bar="/tmp" 

2  prove  auth  ($_PRIN,  read,  $foo)  /pi  >  pf 
inject  pf 

3  for  x  in  'Is  $foo‘;  do  x=$foo/$x 

4  y=$x 

5  _RET="_";  base  $x;  x=$_RET 

6  _RET="_";  path  $foo  $x;  z=$_RET 

7  _RET="_";  extension  $z  "log";  if  [  $_RET  =  "ok"  ];  then 

8  inject  /pf/1  -subst  $_PRIN  $z  $x  $y  $bar  $foo 

9  touch  $z 

10  fi 

11  _RET="_";  path  $bar  $x;  z=$_RET 

12  inject  /pf/2  -subst  $_PRIN  $z  $x  $y  $bar  $foo 

13  inject  /pf/3  -subst  $_PRIN  $z  $x  $y  $bar  $foo 

14  cp  $y  $z 

15  done 

Figure  1:  Translation  of  an  input  program  P,  via  an  intermediate  program  Q,  to  an  output 
script  S.  (The  configuration,  policy,  and  rewrite  theory  provided  to  the  compiler  are  shown 
elsewhere.) 
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•  for  any  principal  A,  file  x,  and  directory  y,  if  x  is  in  y  and  A  has  permission  read  on 
y,  then  A  has  permission  read  on  x,  and  furthermore,  if  x  has  extension  "log"  then 
A  has  permission  write  on  x. 

Finally,  consider  the  following  theory  on  the  function  symbols  path  and  base,  that  abstracts 
the  concrete  semantics  of  these  functions. 

Theory 

l - 1 

Vx.Vy.  member(x, y)  path(y,  base(x))  =  x 

I _ I 


Given  the  configuration,  policy,  and  theory  above,  our  compiler  automatically  translates 
P  to  the  intermediate  program  Q  in  Figure  1.  In  Q,  all  assert  statements  except  that 
in  line  2  are  eliminated,  since  the  compiler  can  infer  that  they  must  succeed  at  run  time. 
Such  inference  requires  collection  of  path  conditions,  partial  evaluation  of  terms  modulo 
the  given  equational  theory,  and  calls  to  the  theorem  prover.  We  describe  the  compiler  in 
detail  in  Sections  4  and  5. 

In  particular,  for  the  assert  statement  in  line  8,  the  compiler  reasons  automatically 
as  follows.  Let  _PRIN  be  the  principal  running  the  script.  Line  8  is  reached  only  if  the 
following  conditions  hold  for  some  z,  x,  x',  and  foo: 

(1)  extension(z,  "log"). 

(2)  z  =  path(foo,  x). 

(3)  x  =  base(x'). 

(4)  member(x/,  f  oo). 

(5)  The  statement  assert  (read,  foo)  in  line  2  succeeds. 

From  condition  (5),  we  can  conclude  that 

(6)  auth(_PRIN,  read,  foo). 

Simplifying  conditions  (2),  (3),  and  (4)  using  the  given  theory,  we  have 

(7)  z  =  x'. 

Now  from  conditions  (1),  (4),  (6),  and  (7)  and  the  given  policy,  the  theorem  prover  can 
conclude  that  auth(_PRIN,  write,  z),  which  is  sufficient  to  eliminate  the  assert  statement 
in  line  8. 

Next,  we  want  to  be  able  to  run  the  intermediate  program  Q  on  a  file  system  that 
supports  PCA.  The  compiler  translates  Q  to  the  equivalent  Bash  script  S  in  Figure  1. 
The  commands  prove  and  inject  perform  functions  described  in  Section  2.  The  header 
(the  part  of  S  before  the  numbered  lines)  defines  all  free  variables  (_PRIN  and  foo)  and 
uninterpreted  functions  and  predicates  (path,  base,  extension)  in  P.  The  implementations 


of  such  functions  and  predicates  are  sound  with  respect  to  the  equational  theory  used  by 
the  compiler. 

We  close  this  section  by  discussing  our  trust  assumptions.  A  policy  is  trusted,  so  any 
interpreted  predicates  in  a  policy  (such  as  member  and  extension)  must  have  trusted  imple¬ 
mentations  (provided  by  the  system).  In  contrast,  a  program  is  not  trusted.  The  compiler 
may  or  may  not  be  trusted.  If  the  compiler  is  trusted,  then  the  system  can  trust  scripts 
produced  by  the  compiler,  and  run  such  scripts  without  checking  the  proofs  that  they  inject. 
This  is  significant  in  implementations  where  proofs  may  be  large  and  proof  verification  may 
be  costly.  However,  such  a  compiler  cannot  assume  semantic  properties  of  the  functions  used 
in  a  program  (such  as  base  and  path)  unless  those  functions  have  trusted  implementations 
that  are  provided  by  the  system.  On  the  other  hand,  if  the  compiler  is  not  trusted  then  the 
system  must  run  all  scripts  with  access  checks.  We  implicitly  assume  the  latter  scenario 
in  the  sequel,  and  provide  additional  guarantees  for  the  scenario  in  which  the  compiler  is 
trusted  (Theorem  4.2). 

4  PCAL:  Syntax,  Semantics,  and  Compilation 

We  now  describe  the  PCAL  language  and  its  compiler.  We  present  the  syntax  of  PCAL 
programs,  define  their  operational  semantics,  formalize  our  compilation  procedure  and  show 
that  it  preserves  the  behavior  of  programs. 

For  simplicity  of  presentation,  we  abstract  various  details  of  the  implementation.  (See 
Section  5  for  a  more  detailed  discussion.)  Instead  of  Bash,  we  consider  an  extension  of 
PCAL  as  the  target  language  for  compilation;  programs  in  this  target  language  can  be 
easily  rewritten  to  Bash.  We  also  treat  all  function  symbols  as  uninterpreted,  although  in 
principle,  equations  over  terms  may  be  freely  added  in  the  run  time  semantics  (to  model 
concrete  implementations)  and  in  the  compiler  (to  model  abstract  properties  of  such  imple¬ 
mentations). 

We  assume  that  r/,  x,  and  t  range  over  permissions,  variables,  and  terms  whose  grammars 
are  borrowed  from  the  logic  used  to  represent  policies.  <p  denotes  a  logical  predicate  whose 
truth  depends  only  on  the  system  state  (i.e.,  a  predicate  that  is  not  defined  by  logical 
rules).  PCAL  programs  are  sequences  of  statements  e  described  by  the  grammar  below. 
Directories,  files,  and  paths  are  represented  as  terms,  and  x  is  a  special  variable  that  is 
bound  to  the  principal  running  a  program. 

Syntax 


for  x  in  t  {P} 
test  ip  {P} 
x  =  t 

shell  n(ti, . . . ,  tk) 
assert  (rj,t) 

P,  Q  ::  = 


statements 

for  each  file  /  in  directory  t,  bind  x  to  /  and  do  P 
if  condition  p  holds,  do  P 
assign  i  to  i 

call  shell  command  n  with  parameters  t\ , . . . , 
assert  that  principal  x  has  permission  r/  on  path  t 
programs 
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e;  Q 

end 


run  e,  then  do  Q 
skip /halt 


We  also  consider  below  an  extension  of  PCAL  which  acts  as  the  target  language  for  the 
compiler,  a  =  prove  (77,  t)  and  inject  (77,  t)  7  are  formal  representations  of  the  commands 
prove  and  inject  from  Section  2.  7  ranges  over  proofs  and  a  denotes  a  variable  bound  to 
a  proof  (which,  in  the  actual  implementation,  is  a  temporary  file  that  stores  the  proof;  see 
Section  5). 

Extended  syntax 

I - 

e  ::= 

a  =  prove  (77,  t) 
inject  (rf,t)  7 


statements 

prove  that  principal  x  has  permission  77  on  path  t 
and  bind  the  proof  to  a 
inject  proof  7  that  authorizes  (x,  ??,  t) 


Semantics 

A  PCAL  program  runs  in  an  environment  6  of  the  form  (A,£),  where  A  is  a  function 
from  shell  command  names  to  lists  of  permissions  (configuration)  and  C  is  the  set  of  logical 
formulas  used  to  determine  access  (policy).  Informally,  if  A(n)  =  771, ...  ,777,  then  executing 
shell  command  n(t\, . . . ,  tk)  requires  permissions  771, ... ,  7)k  on  paths  t±, . . . ,  tk  respectively. 

A  state  p  is  a  triple  (H,  S,  £),  where  H  is  an  abstract,  logical  representation  of  the  part 
of  the  system  state  on  which  proofs  of  access  depend,  S'  is  a  function  from  paths  to  terms 
(data  store),  and  £  is  a  partial  function  from  triples  (A,  77,  t)  to  proofs  (proof  store).  H  must 
contain,  at  the  least,  information  about  members  of  directories.  We  write  members(iL,  t)  to 
denote  the  list  of  files  in  directory  t  in  the  system  state  H.  Proofs  injected  using  inject  (77,  t)  7 
are  added  to  £. 

Reductions  are  of  the  form  p,P  p',P',  meaning  that  program  P  at  state  p,  run 

by  principal  x  in  environment  6,  reduces  to  program  P'  at  state  p' .  The  reduction  rules 

n(t  i,...,tfc) 

are  shown  in  Figure  2.  H,  S  ►  H  ,  S  means  that  executing  the  shell  command 
n(ti, . . . ,  tk)  updates  the  system  state  H  and  data  store  S  to  H'  and  S'  respectively.  H  |=  <p 
means  that  ip  holds  in  H,  and  H  \/=  <p  means  that  <p  does  not  hold  in  H.  In  practice,  whether 
(p  holds  in  H  or  not  is  decided  using  a  trusted  decision  procedure  provided  by  the  system. 

•  (Reduct  for)  unrolls  a  loop  P  for  each  file  x  in  a  directory  t.  (Reduct  test) 
simplifies  test  ip  {I3};  Q  to  P;  Q  if  H  |=  (p,  and  to  Q  otherwise.  (Reduct  assign)  is 
straightforward. 


•  (Reduct  shell)  finds  proofs  71,..., 7n  needed  to  authorize  the  shell  command 
n(ti, . . .  ,tk)  in  the  proof  store  £.  It  then  checks  these  proofs  (premise  7 i  ::  H;jC  h 

auth(%,  ?7j,  tj)),  and  executes  the  shell  command  (premise  H,  S  ►  H' ,  S'). 
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Reduction  p,  P 


^p',P' 


(Reduct  for) 

(Reduct  test) 
(Reduct  assign) 


p  =  ( H ,  _)  members (H,  t)  =  t±, . . . ,  tk 

p,  for  x  in  t  {P};  Q  p,  P{ti/x}\ . . . ;  P{tk/x}\  Q 

P  =  (H,  _)  H  \=  <p  p  =  (H,  _)  H  \f  <p 


(Reduct  shell) 

(Reduct  assert) 

(Reduct  prove) 

(Reduct  inject) 


p,  test  ip  {P};  Q  p,  P;  Q  p,  test  {P};  Q  p,  Q 
p,x  =  t\Q  ^  p,  Q{t/x} 

Q  =  (A,£)  A(n)  p=(H,S,0 

£(x>  Vi,  U)=li  ji  ::  H;C\-  auth(x,  Vi,  U) 

H,S  ►  if',  5'  p'  =  (H',S',£) 

p,  shell  n(ti, . . . ,  4);  P  ^  p',P 

0  =  (-,£)  p=(H,S,£) 

H;C\-  auth(x,  V,t)\'y  p'  =  (H,  S,  £[(x,  V,  t)  >->■  7]) 
p,  assert  (77,  t);  P  7/,  P 

0  =(-,£)  P  =(#,-,-)  H-,C\-  auth(x,  77,  t)  \  7 

P,  a  =  prove  (77,  t);  P  p,  Pjy/a} 

p=(H,S ,£)  7/  =  ^  7]) 

p,  inject  (77,  t)  7;P  p',P 


Figure  2:  Reduction  rules 


•  (Reduct  assert)  calls  the  theorem  prover  to  construct  a  proof  7  which  shows  that 
X  has  permission  77  on  path  t  (premise  H;C\~  auth(x,  V,  t)  \  7),  and  passes  it  to  the 
system  interface  by  placing  it  in  the  store  £. 

•  (Reduct  prove)  constructs  a  proof  7  and  binds  a  to  it.  (Reduct  inject)  places  a 
proof  7  in  the  proof  store  £.  By  these  rules,  the  effect  of  the  command  sequence  a  = 
prove  (77,  f);  inject  (77,  t)  a  is  exactly  the  same  as  the  command  assert  (77 ,t).  However, 
assert  (77,  t)  occurs  only  in  source  programs  whereas  prove  (77,  t)  and  inject  (77,  t)  7  occur 
only  in  compiled  programs. 

Compilation 

Next,  we  formalize  compilation  of  PCAL  programs.  As  the  compiler  traverses  a  program, 
it  maintains  a  database  of  facts  that  must  be  true  at  the  program  point  that  the  compiler 
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is  looking  at.  These  facts  are  formally  represented  by  T  =  (a,  <&,  S). 

•  o  is  a  list  of  substitutions  of  the  form  {t/x}.  The  latter  means  that  program  variable 
x  is  bound  to  term  t. 

•  $  is  a  list  of  interpreted  predicates  p  that  can  be  assumed  to  hold  at  a  program  point. 
These  are  gathered  from  commands  test  p  {. . .}  and  for  x  in  t  {. . In  particular, 
p  may  be  of  the  form  member meaning  that  path  t!  is  in  directory  t;  and  we 
assume  that  members [H,  t)  =  t\, . . . ,  implies  H  1=  member (fi,  t)  A  •  •  •  A  member (t*,,  t) . 

•  S  is  a  partial  function  from  triples  (.A,  77,  t )  to  authorization  proofs  that  the  compiler 
has  already  constructed. 

Figure  3  shows  the  rules  to  derive  judgments  of  the  form  ThP  AT  P',  meaning  that  under 
assumptions  T,  program  P  compiles  to  program  P'  in  environment  0  and  system  state  H. 
X  is  given  to  the  compiler  at  the  time  of  invocation;  it  represents  the  user  who  is  expected 
to  run  the  compiled  program.  Pi  is  the  state  of  the  system  in  which  the  compiled  program 
is  expected  to  run.  It  may  either  be  the  system  state  at  the  time  of  compilation  (if  it  is 
expected  that  the  compiled  program  will  run  in  the  same  state),  or  it  may  be  a  state  that 
the  user  provides.  Both  x  and  H  are  needed  to  call  the  theorem  prover  during  compilation. 

For  any  syntactic  entity  E,  we  write  Eu  to  denote  the  result  of  applying  the  substitution 
i 7  to  E.  W(P)  denotes  the  variables  that  are  assigned  in  the  program  P,  and  o\x  denotes 
the  restriction  of  o  that  removes  the  mappings  for  all  variables  in  x.  Finally,  |S|  and  (S) 
extract  the  formulas  and  proofs  in  E  (n  denotes  tripling  of  proofs): 

|E|  =  f\  auth(A,  rj,  t)  (E)  =  7 

(A,?j,t)edom(S)  7£rng(H) 


•  (Comp  end)  terminates  compilation  when  end  is  seen. 

•  (Comp  for)  compiles  for  x  in  t  {P};  Q  by  compiling  P  to  P'  under  the  added  assump¬ 
tion  member(x,  ta)  (which  must  hold  inside  the  body  of  the  loop),  and  compiling  Q 
to  Q' .  In  each  case,  any  prior  substitutions  for  variables  x  assigned  in  P  are  removed 
from  <7,  because  they  may  be  invalidated  during  the  execution  of  the  loop  (premises 
x  =  W(P)  and  o'  =  o\x). 

•  (Comp  test)  is  similar  to  (Comp  for);  in  this  case  the  assumption  po  is  added 
when  compiling  the  body  P  of  the  test  branch. 

•  (Comp  assign)  records  the  effect  of  assignment  x  =  t  by  augmenting  substitution  o 
with  {to/x}.  This  augmented  substitution  is  used  to  compile  the  remaining  program. 

•  (Comp  shell)  checks  that  there  is  a  proof  in  the  set  of  previously  constructed  proofs  E 
to  authorize  each  permission  needed  to  execute  a  shell  command  n(ti, . . . ,  tfc).  (Proofs 
are  added  to  this  set  in  the  next  two  rules). 
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Compilation  T  b  P  H-^x  P' 


1 

(Comp  end) 

1 

r  b  end  H£>x  end 

(Comp  for) 

r  =  (cr,  T,  S)  x  =  W(P)  o'  =  o\x 

x  fresh  in  T  $'  =  $,  member (x,  to) 

(o',  S)  b  P  H&x  P'  (o',  $,  3)  b  Q  H&x  Q' 

r  b  for  x  in  t  {P};  Q  H£>x  for  x  in  t  {P'};  Q' 

(Comp  test) 

r  =  (cr,$,H)  x  =  W(P)  o'  =  a\x  <!>'  =  <I>,  ipa 

(0,  S)bP  p>  (o',  $,  5)  b  Q  H£x  Q' 

r  b  test  ip  {-P};  Q  H^ix  test  tp  {P' };  Q' 

(Comp  assign) 

r  =  (0,  T,  S)  o'  =  er[a;  t— ►  to]  (o' ,  T,  S)  b  P  H£>x  P' 

r  b  x  =  t-,p  H£x  x  — 1\  p' 

(Comp  shell) 

d=(A,_)  A(n)  =  771 ,  —  ,  77fc  r=(cr,_,H) 

(x,  7 li,ti&)  €  dom(S)  for  each  i  T  b  P  H^x  P' 

T  b  shell  n(ti, . . .  ,tfc);  P  H&x  shell  n(t\, . . .  ,tk)\  P' 

(Comp  static) 

r=(a,T,S)  e  =(_,£) 

H,  T;  C  b  |S|  =>  auth(x,  77,  to)  \  7'  7  =  7'  (S) 

s'  =  S[(x,  77,  to)  ^7]  r'  =  (a,  t,  S')  r'bP  H£x  p' 

r  b  assert  (77,  t);  P  H&x  inject  (77,  t)  7;  P' 

(Comp  dynamic) 

1 _ 

r  =  (0,  T,  S)  9  =  (.,£) 

fp,  T;  £  b  |S  =>  auth(y,  77,  to)  X,  a  fresh  in  T,  P 

S'  =  S[(X,T7  ,to)~a]  r'  =  (a,T,S')  r'bP^’V' 

T  b  assert  (77,  t);  P  cr  =  prove  (77,  i);  inject  (77,  t)  cr;  P' 

_ 1 

Figure  3:  Compilation  rules 


•  (Comp  static)  and  (Comp  dynamic)  are  used  to  compile  the  command  assert  (77,  t) 
in  different  cases.  To  decide  which  rule  to  use,  the  compiler  tries  to  statically  prove 
|H|  =b  auth(y,  77,  to)  by  calling  the  theorem  prover.  The  context  in  which  the  proof 
is  constructed  not  only  contains  H  and  the  policy  £,  but  also  information  about 
directory  memberships  and  predicates  tested  in  outer  scopes  (Ter).  If  a  proof  7'  can 
be  constructed,  rule  (Comp  static)  is  used:  assert  (77,  t)  is  replaced  by  inject  (77,  t)  7, 
which  passes  the  statically  generated  proof  7  =  7'  (E)  to  the  system  interface  at  run 
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time,  (y  (E)  is  the  proof  of  auth(y,  77,  ta)  obtained  by  eliminating  the  connective  =7- 
frorn  |S|  =7-  auth(x,  rj,  tcr)).  Also,  the  fact  that  the  new  proof  exists  is  recorded  by 
updating  S  to  E;  =  S[(y,  r],  ta)  >  7],  and  using  E;  to  compile  the  remaining  program 
P.  If  the  proof  construction  fails,  rule  (Comp  dynamic)  is  used:  the  compiler 
generates  code  both  to  construct  the  proof  at  run  time  and  to  inject  it  into  the  system 
interface.  Accordingly,  assert  (rj,t)  is  compiled  to  a  =  prove  (77,  t);  inject  (77,  t)  a.  Even 
in  this  case,  it  is  safe  to  assume  that  a  proof  of  auth(y,  77,  ta)  will  exist  when  P  executes 
(else  a  =  prove  (77,  t)  will  block  at  run  time),  so  5  is  updated  to  E;  =  S[(y,  77,  ta)  a]. 

Formal  Guarantees 

We  close  this  section  by  stating  two  theorems  that  guarantee  correctness  of  compilation. 
Proofs  of  these  theorems  can  be  found  in  the  related  technical  report  [10].  We  begin  by 
defining  a  preorder  <  on  system  states.  Roughly,  H  <  H'  if  any  formula  that  holds  under 
H  also  holds  under  H1 . 

Definition  4.1  (<).  For  any  H  and  H',  let  H  <  H'  if  for  all  <p,  7,  C,  and  s,  (1)  H  1=  <p 
implies  H'  t=  (p,  and  (2)  7  ::  H;  C  b  s  implies  7  ::  H C\~  s. 

Next,  we  assume  the  following  axioms  for  the  various  external  judgments.  Roughly,  Ax¬ 
iom  (1)  states  that  system  states  are  updated  monotonically  by  shell  command  executions. 
Axioms  (2),  (3),  and  (4)  state  that  verification  of  proofs  must  be  closed  under  substitution, 
modus  ponens,  and  product.  Axiom  (5)  states  that  the  theorem  prover  produces  only  veri¬ 
fiable  proofs  ( i.e .,  the  theorem  prover  is  sound).  Axiom  (6)  states  that  the  theorem  prover 
always  produces  a  proof  if  some  proof  exists  (i.e.,  the  theorem  prover  is  complete). 

Axioms 

I - 1 

n(ticr,...,tkcr) 

(1)  if  H,S  ►  H’,  S'  then  H  <  H' 

(2)  if  7  ::  H;  C  b  s  then  ja  ::  Ha;  C\~  sa 

(3)  if  7  ::  H;  C  b  s  and  7'  ::  H;  C  h  s  =7  s'  then  (7'  7)  ::  H;  C\~  s' 

(4)  if  7j  ::  H;  C  h  Sj  for  each  i  £  l..n,  then  (  n  7 i)  ■■H;CY-  /\  Si 

iEl..n  i£l...n 

(5)  if  H ;  C  b  s  \  7  then  7  : :  H;  C  b  s 

(6)  if  7  ::  H;  C  b  s  then  H;  C  b  s  \  7'  for  some  7'. 

I _ l 

We  can  now  show  that  compilation  preserves  the  behavior  of  programs.  More  precisely, 
if  a  program  P  compiles  to  a  program  P'  under  a  system  state  H,  and  the  programs  are 
run  from  a  system  state  H'  such  that  H  <  H' ,  then  P  and  P'  evaluate  to  the  same  state. 
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Theorem  4.1  (Compilation  correctness).  Suppose  that  Axioms  (1-6)  hold,  and  (0,  0,  0)  h 

M 

P  -w  p'.  P/ien  for  all  A  and  p  =  (H' ,  _,  _)  such  that  H  <  H’ ,  we  have  p,  P  — p' ,  Q  for 

e, A  e, A 

some  Q  if  and  only  if  p,P'  — >*  P*,Q'  for  some  Q' .  ( — >*  denotes  the  reflexive-transitive 
closure  of 

Finally,  we  show  that  a  compiled  program  can  never  fail  due  to  an  access  check,  if  the 
policy  does  not  change  between  compile  time  and  run  time.  Formally,  compilation  preserves 
the  behavior  of  programs  even  if  the  compiled  programs  are  run  without  access  checks. 

Definition  4.2  (=>).  Let  =$■  be  the  same  reduction  relation  as  — >  except  that  the  rule 
(Reduct  shell)  is  replaced  by  the  following  rule,  which  differs  from  the  earlier  version  in 
that  its  premises  do  not  mention  any  proofs. 

e  =  (  A,£) 

n(t 

A(n)  =  pi, . . .  ,r]k  p  =  (H,  S,  f)  H,  S  ►  H',S'  p'  =  {H',S',Q 

P,  shell  n(ti, . . .  ,4);  P  p',P 

Theorem  4.2  (Access  control  redundancy) .  Suppose  that  Axioms  (1-6)  hold,  and  (0,  0,  0)  h 

M 

P  L+  P' .  Then  for  all  A  and  p  =  (Hf  _,  _)  such  that  H  <  H' ,  we  have  p,  P'  — p' ,  Q  for 

9,  A 

some  Q  if  and  only  if  p.  P'  p' ,  Q'  for  some  Q' . 

Before  we  close  this  section,  let  us  point  out  some  consequences  of  our  axioms.  Axioms 
(2),  (3),  (4),  (5)  represent  standard  expectations  from  the  proof  system  and  the  theorem 
prover.  Axiom  (6)  is  required  to  prove  soundness  of  the  compiler  (“if”  direction  of  Theo¬ 
rem  4.1)  since,  in  its  absence,  there  is  no  guarantee  that  a  statically  provable  authorization 
will  be  successfully  proved  in  the  rule  (Reduct  assert)  when  executing  the  source  program 
directly.  Axiom  (1)  is  needed  for  a  similar  purpose;  without  this  axiom,  the  compiler  must 
throw  away  assumptions  on  the  system  state  in  the  continuation  of  any  shell  command. 
However,  the  axiom  may  seem  too  strong  and  invalid  in  practice.  Fortunately,  weaker  ver¬ 
sions  of  this  axiom  suffice  to  prove  our  theorems  for  specific  programs.  In  particular,  the 
definition  of  H  <  H'  may  be  qualified  to  require  that  H  \=  <p  imply  H'  \=  tp  for  only  those  ip 
that  appear  in  a  program  of  interest  (and  their  substitution  instances). 

5  Implementation 

We  have  implemented  a  prototype  PCAL  compiler  and  tested  it  on  the  proof-carrying  file 
system  PCFS  [18].  The  specific  logic  currently  used  in  our  implementation  is  BL  [16, 
18].  The  interested  reader  can  find  a  complete  example  (involving  homework  management 
between  instructors  and  students  of  various  courses)  in  the  appendix.  We  now  discuss  some 
implementation  details  that  are  left  abstract  in  Section  4. 
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Rewrite  rules 

A  set  of  rewrite  rules  over  terms,  modeling  abstract  properties  of  the  concrete  implemen¬ 
tations  of  function  symbols,  can  be  provided  to  the  compiler  to  improve  its  precision.  The 
compiler  constructs  a  normalization  function  based  on  these  rules,  and  applies  this  function 
eagerly  to  substitutions.  This  works  well  even  in  cases  where  it  is  not  possible  to  interpret 
function  symbols  with  directed  clauses  in  the  policy.  (Modeling  equations  as  clauses  usually 
causes  proof  searches  to  loop.) 

Quantified  proofs 

Statically  generated  proofs  may  contain  free  variables,  and  as  such  they  are  parametric  over 
those  variables.  In  the  formal  semantics,  such  proofs  are  bound  and  carried  as  values  in 
the  language  (in  inject  statements),  so  they  get  implicitly  instantiated  before  injection  at 
run  time.  However  in  our  actual  implementation,  such  proofs  are  output  to  temporary  files 
with  distinct  names  (under  /.pf),  and  the  names  are  carried  in  the  language;  so  the  free 
variables  in  such  proofs  must  be  explicitly  substituted  at  run  time.  This  explains  why  we 
considered  an  explicit  -subst  option  to  the  inject  command  in  Section  2. 

6  Conclusion 

PCAL  combines  static  checks  and  dynamic  theorem  proving  to  automate  correct  and  effi¬ 
cient  use  of  a  PCA-based  interface.  PCAL’s  compiler  is  modular:  it  is  parametric  over  both 
the  shell  commands  (system  interface)  and  the  logic  it  supports.  Although  this  makes  the 
compiler  flexible,  the  interaction  between  the  core  language,  shell  commands,  and  the  logic 
is  subtle  and  requires  careful  design.  The  compiler  is  made  practical  through  a  combination 
of  simple  user  annotations,  static  constraint  tracking,  dynamically  checked  assertions,  and 
run  time  support  from  a  command  line  theorem  prover.  We  prove  formally  that  these  ideas 
work  well  together.  It  is  our  belief  that  PCAL’s  design  is  novel,  and  that  it  will  be  a  useful 
stepping  stone  for  languages  that  support  rule-based  access  control  interfaces  in  future. 

There  are  several  interesting  avenues  for  future  work.  An  obvious  one  is  to  run  realistic 
examples  on  PCAL,  to  determine  what  other  features  are  needed  in  practice.  Another 
possible  direction  is  a  code  execution  architecture  where  a  trusted  PCAL  compiler  is  used 
to  generate  certified  scripts  that  are  run  with  minimal  access  control  checks.  Finally,  it 
will  be  interesting  to  apply  ideas  from  PCAL,  particularly  the  use  of  an  automatic  theorem 
prover,  in  the  context  of  language-based  security  for  access  control  interfaces  (e.g.,  [4,20]). 


References 

[1]  Martin  Abadi.  Access  control  in  a  core  calculus  of  dependency.  Electronic  Notes  in 
Theoretical  Computer  Science,  172:5-31,  2007.  Computation,  Meaning,  and  Logic: 
Articles  dedicated  to  Gordon  Plotkin. 


16 


[2]  Martin  Abadi,  Michael  Burrows,  Butler  Lampson,  and  Gordon  Plotkin.  A  calculus  for 
access  control  in  distributed  systems.  ACM  Transactions  on  Programming  Languages 
and  Systems ,  15(4)  :T06— 734,  1993. 

[3]  Andrew  W.  Appel  and  Edward  W.  Felten.  Proof-carrying  authentication.  In  ACM 
Conference  on  Computer  and  Communications  Security  (CCS  ’ 09 ),  pages  52-62.  ACM, 
1999. 

[4]  Kumar  Avijit,  Anuparn  Datta,  and  Robert  Harper.  PCML5:  A  language  for  ensuring 
compliance  with  access  control  policies,  2009.  Draft,  personal  communication. 

[5]  Lujo  Bauer.  Access  Control  for  the  Web  via  Proof-Carrying  Authorization.  PhD  thesis, 
Princeton  University,  2003. 

[6]  Lujo  Bauer,  Scott  Garriss,  Jonathan  M.  McCune,  Michael  K.  Reiter,  Jason  Rouse, 
and  Peter  Rutenbar.  Device-enabled  authorization  in  the  Grey  system.  In  Information 
Security  Conference  (ISC  ’05),  LNCS,  pages  431-445,  2005. 

[7]  Moritz  Y.  Becker,  Cedric  Fournet,  and  Andrew  D.  Gordon.  Design  and  semantics 
of  a  decentralized  authorization  language.  In  IEEE  Computer  Security  Foundations 
Symposium  (CSF  ’07),  pages  3-15.  IEEE,  2007. 

[8]  Jesper  Bengtson,  Karthikeyan  Bhargavan,  Cedric  Fournet,  Andrew  Gordon,  and  Sergio 
Maffeis.  Refinement  types  for  secure  implementations.  In  IEEE  Computer  Security 
Foundations  Symposium  (CSF  ’08),  pages  17-32.  IEEE,  2008. 

[9]  Avik  Chaudhuri  and  Martin  Abadi.  Secrecy  by  typing  and  file-access  control.  In  IEEE 
Computer  Security  Foundations  Workshop  (CSFW’06),  pages  112-123.  IEEE,  2006. 

[10]  Avik  Chaudhuri  and  Deepak  Garg.  PCAL:  Language  support  for  proof-carrying  au¬ 
thorization  systems.  Technical  Report  CMU-CS-09-141,  Carnegie  Mellon  University, 
2009. 

[11]  Avik  Chaudhuri,  Prasad  Naldurg,  and  Srirarn  Rajamani.  A  type  system  for  data-flow 
integrity  on  Windows  Vista.  In  ACM  SIGPLAN  Workshop  on  Programming  Languages 
and  Analysis  for  Security  (PLAS’08),  pages  89-100.  ACM,  2008. 

[12]  John  DeTreville.  Binder,  a  logic-based  security  language.  In  IEEE  Symposium  on 
Security  and  Privacy  (S&P’02),  pages  105-113.  IEEE,  2002. 

[13]  Corrnac  Flanagan.  Hybrid  type  checking.  In  ACM  Symposium  on  Principles  of  Pro¬ 
gramming  Languages  (POPL’06),  pages  245-256.  ACM,  2006. 

[14]  Cedric  Fournet,  Andrew  Gordon,  and  Sergio  Maffeis.  A  type  discipline  for  authorization 
in  distributed  systems.  In  IEEE  Computer  Security  Foundations  Symposium  ( CSF  ’07), 
pages  31-48.  IEEE,  2007. 


17 


[15]  Deepak  Garg.  Principal-centric  reasoning  in  constructive  authorization  logic.  Technical 
Report  CMU-CS-09-120,  Carnegie  Mellon  University,  2009. 

[16]  Deepak  Garg.  Proof  search  in  an  authorization  logic.  Technical  Report  CMU-CS-09- 
121,  Carnegie  Mellon  University,  2009. 

[17]  Deepak  Garg  and  Frank  Pfenning.  Non-interference  in  constructive  authorization  logic. 
In  IEEE  Computer  Security  Foundations  Workshop  ( CSFW  ’06),  pages  283-293.  IEEE, 
2006. 

[18]  Deepak  Garg  and  Frank  Pfenning.  A  proof-carrying  file  system.  Technical  Report 
CMU-CS-09-123,  Carnegie  Mellon  University,  2009. 

[19]  Yuri  Gurevich  and  Itay  Neernan.  DKAL:  Distributed-knowledge  authorization  lan¬ 
guage.  In  21st  IEEE  Symposium  on  Computer  Security  Foundations  (CSF-21),  2008. 

[20]  Lirnin  Jia,  Jeffrey  A.  Vaughan,  Karl  Mazurak,  Jianzhou  Zhao,  Luke  Zarko,  Joseph 
Schorr,  and  Steve  Zdancewic.  Aura:  A  programming  language  for  authorization  and 
audit.  In  ACM  International  Conference  on  Functional  Programming  (ICFP  ’08). 
ACM,  2008. 

[21]  Butler  Lampson,  Martin  Abadi,  Michael  Burrows,  and  Edward  Wobber.  Authentica¬ 
tion  in  distributed  systems:  Theory  and  practice.  ACM  Transactions  on  Computer 
Systems,  10(4):265-310,  November  1992. 

[22]  Chris  Lesniewski-Laas,  Bryan  Ford,  Jacob  Strauss,  Robert  Morris,  and  M.  Frans 
Kaashoek.  Alpaca:  Extensible  authorization  for  distributed  services.  In  ACM  Confer¬ 
ence  on  Computer  and  Communications  Security  ( CCS  ’07).  ACM,  2007. 

[23]  Andrew  Pimlott  and  Oleg  Kiselyov.  Soutei,  a  logic-based  trust-management  system. 
In  Eighth  International  Symposium  on  Functional  and  Logic  Programming  (FLOPS 
2006),  pages  130-145,  2006. 

[24]  Jeffrey  A.  Vaughan,  Lirnin  Jia,  Karl  Mazurak,  and  Steve  Zdancewic.  Evidence-based 
audit.  In  IEEE  Symposium  on  Computer  Security  Foundations  (CSF  ’08).  IEEE,  2008. 

A  Proofs 

A.l  Proof  of  Theorem  4.1 

In  the  following  proof,  we  use  a  non-deterministic  version  of  our  compilation  relation,  with 

the  following  changes. 

1.  (Comp  static)  can  guess  any  proof  that  works,  not  necessarily  a  proof  returned  by 
the  theorem  prover. 
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r  =  (a,$,s)  e  =  (_,£) 

y  ::  F,  <t>;  £  b  |S|  =7  auth(y,  77,  hr)  7  =  7'  (■=■)  =  7^ 

S"  =  S[(y,77,to-)  -y]  T' =  (a,<5>,~')  C  b  P  H&x  P' 

T  b  assert  (77,  t);  P  H£ix  inject  (77,  t)  7;  P' 


2.  (Comp  dynamic)  can  be  applied  whenever  (Comp  static)  can  be  applied. 

r  =  (cr,  $,S)  9  =  (_,£)  a  fresh  in  F,  P 

E1  =  E[(X,  77,  to)  ^  a]  r'  =  (a,  $,  S')  C  b  P  P' 

T  b  assert  (77,  f);  P  a  =  prove  (77,  t);  inject  (77,  t)  a;  P' 

Note  that  these  changes  allow  some  more  programs  to  be  compiled,  but  no  less;  thus, 
they  do  not  affect  the  soundness  of  our  results. 

We  begin  with  a  few  basic  lemmas.  We  assume  that  if  (<7,  $,E)  b  P  bb  P1  then 
(fv($)  U  fv(E))  n  dom(cj)  =  0;  note  that  this  invariant  is  preserved  by  our  typing  rules. 

H  6  x 

Lemma  A.l.  Suppose  that  (d,$,S)bP  P’  and  x  ^  dom(<r). 

Then  ( a[x  1— >  ter],  &{tcr /x},  E{tcr/x})  b  P  P' . 

Proof.  By  induction  on  the  derivation  of  the  compilation  judgment  for  P.  The  only  inter¬ 
esting  case  is  (Comp  static),  where  we  use  Axiom  (2). 

Case  P  =  assert  (77,  t);  Q  and  P’  =  inject  (77 ,t)  7;  Q' 
such  that  6  =  (_,  C), 
i  -  H,  C  b  |E|  =7  auth(y,  77,  ter), 

7  =  V  (S), 
s  =  E[(x,vM)  ^  7]. 

and  (a,  <h,  E)  b  Q  H~4X  Q' . 

Let  a'  =  {t'a/x}. 

We  require  ( a[x  i— >■  t'er],  Qcr' ,  Ea')  b  P  H^X  P' . 

By  Axiom  (2),  7 'a'  ::  H,  Ter';  C  b  |E<r,|  =7  auth(y,  77,  tcrcr'). 

Also,  by  assumption,  (a[x  t'er],  Ter' ,  Ecr')  b  Q  bb'x  Q'. 

The  result  follows. 


□ 

H  6  v 

Lemma  A. 2.  Suppose  that  (cr[x  1—7  ta],  T,  S)bP  P'. 

Then  (cx,  T,  5)  b  P{t/x}  H£X  P'{t/x}. 

Proof.  By  induction  on  the  derivation  of  the  compilation  judgment  for  P.  □ 
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Lemma  A. 3.  Suppose  that  ( a ,  <h,  H)  b  P  H&x  P1 ,  x  =  W(P),  and  (a\x,  $,  S)  h  Q  H^4X  Q' . 
Then  {a,  $,  S )  h  P;  Q  H&x  P';  Q1 . 

Proof.  By  induction  on  the  derivation  of  the  compilation  judgment  for  P.  The  only  inter¬ 
esting  cases  are  (Comp  assign),  where  we  use  Lemma  A.l,  and  (Comp  for)  and  (Comp 
test),  which  are  similar  but  do  not  require  any  additional  lemma.  Let  T  =  (a,  <h,  S). 

Case  P  =  for  x  in  t  {P};  Q 

Then  P'  =  for  x  in  t  {P'}‘,  Q’  such  that 
x  is  fresh  in  T, 

$  =  T,member(x,fcr), 
z  =  W(P), 

(a\Z,$,E)hPH&x  P7, 

and  (cr\z,  $,  E)  b  Q  H’^4X  Q’ . 

By  assumption,  x  =  z  U  W(Q) 

and  (a\x,  T,  E)  b  Q  H^4X  Q1 . 

We  need  (a\z,  T,  E)  b  Q;  Q  H^x  Q';  Q' . 

The  result  follows  by  the  inductive  hypothesis. 

Case  P  =  test  p  {P};  Q 

Then  P’  =  test  ip  {P7} ;  Q'  such  that 
z  =  W(P), 

T  =  <h,  pa, 

(a,  $,  5)  \-PH&xPi, 

and  (a\z,  <h,  E)  b  Q  H^ix  Q’ . 

By  assumption,  z  =  xL)W(Q) 

and  (a\x,  T,  E)  b  Q  H^ix  Q'. 

We  need  (a\z,  <f>,  S)  b  Q;Q  H^x  Q’\  Q' . 

The  result  follows  by  the  inductive  hypothesis. 

Case  P  =  (x  =  t\  Q) 

Then  P'  =  (x  =  f;  Q')  such  that 

(< a[x  ta ],  T,  E)  b  Q  H£x  Q' .  ^ 

By  assumption,  x  =  {x}  U  W(Q) 

and  (a\x,  $,  E)  b  Q  H^ix  Q' . 

We  need  (a[x  h- >  ta],  <f>,  S)  b  Q]Q  H^X  Q Q' . 

Let 

•  x  G  W(Q). 

The  result  follows  by  the  inductive  hypothesis. 


20 


x(£W(Q).  ^ 

Then  a\W(Q)  =  (<r\5?)[a:  e- >  ta\. 

The  result  follows  by  Lemma  A.l  and  the  inductive  hypothesis. 


□ 

Building  on  these  basic  lemmas,  the  proof  of  Theorem  4.1  relies  on  the  following  main 
lemma.  Here,  we  write  a  a  when  ap  =  a  and  p  only  substitutes  proofs.  Note  that 
since  terms  t  and  propositions  cp  cannot  contain  proof  variables,  we  always  have  tp  =  t  and 
=  <P- 

Lemma  A. 4.  Suppose  that  Axioms  (1-6)  hold.  Let  a  be  any  ground  substitution,  and  a, 
p  be  such  that  a  <M  a.  Let  6  =  _,  C.  Let  H,  <h,  E,  H,  and  (  be  such  that  H  1=  H, 
and  V(x,  p,  t)  G  dom(S),  we  have  H;  C  h  auth(x,  p,  t)  \  f(x,  p,  t)  and  E(x,  p,  t)p  ::  H;  C  b 
auth  (x,p,t). 

Suppose  that  (a,  <L,  S)  b  P  H^ix  P' . 

•  If  H,  S ,  £,  Pa  — ^  H' ,  S',  Qa'  for  some  Q  and  a 1  then 

H,  S,  Ep,  P'a  -^4  H' ,  S' ,  E'p',  Q'a'  for  some  Q’ ,  p! ,  and  E'  such  that 

a  <^1  a',  (a,&,E')  h  Q  H^x  Q' ,  H'  1=  H,&,  and\/(x,p,t)  E  dom(E/):  H'-,L  b 
auth(x,  p,  t)  \  £'(x,P,t)  and  E'{x,p,t)p'  ::  H'\C  b  auth (x,p,t). 

•  If  H,  S,  Ep,  P'a  — ^  H' ,  S',  f",  Q'a'  for  some  f",  Q' ,  and  a'  then  ("  =  E' p! 

0  Y  ? 

and  H,  S,  £,  Pa  —^4  H' ,  S' ,  Q,  Qa'  for  some  Q,  p! ,  & ,  and  E'  such  that 

a  <jU/  a',  (a,$',E')  b  Q  H&x  Q' ,  H'  1=  H,&,  and\/(x,p,t)  G  dom(E/):  H'-,L  b 
auth(x,  p,  t)  \  £'(x,P,t)  and  E'{x,p,t)p'  ::  H';C\~  auth (x,p,t). 

Q  7  Q 

(Note:  — denotes  zero  or  one  steps  of  — ) 

Proof.  By  induction  on  the  derivation  of  the  compilation  judgment  for  P.  Let  T  =  (a,  $,  E). 

Case  P  =  for  x  in  t  {P};  Q 

Then  P'  =  for  x  in  t  {P'};  Q'  such  that 
x  is  fresh  in  T, 

$  =  <h,member(x,tu), 
x  =  W(P), 

(a\x,$,E)  b  PH£X  P>, 

and  (' a\x ,  $,  E)  h  Q  H^hx  Q' . 

Furthermore,  let 


•  H'  =  H. 
S'  =  S, 

e=t, 
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and  Q  =  Pa\ ; . . . ;  Pc rk;  Q  such  that 

members(P,  ter)  =  t±, . . .  ,tk 

and  oi  =  {p/x},  ...,Ok  =  {tk/x}. 

Then  Q7  =  P70i;...;P70fe;_Q'. 

We  require  (0,  <h7,  E7)  h  Q  H-&x  Q'  for  some  <L7,  H7. 

Let  T7  =  $, member(ti,  tef), . . . , member(t/c,  fix) 
and  E7  =  S. 

Using  the  freshness  assumption  on  x: 

_ j  j  Q  ^ 

By  Lemmas  A.l  and  A. 2  and  weakening,  (a\x,  <b7,  E7)  h  Pu,  -w  Pfo*. 

Furthermore,  by  weakening,  (cf\x,  <b7,  E7)  b  Q  -w  Q'. 

By  Lemma  A. 3,  (<f\5;,  <L7,  E7)  h  P01; . . . ;  Pua-;  Q  H^X  P'a  1; . . . ;  PV*,;  Q' . 
By  construction,  dom(cj7)  H  (fv($7)  U  fv(E7))  =  0. 

The  required  result  follows  by  Lemma  A.l. 

Finally,  we  have 
0  a'  where  //  =  fi, 

p['  1=  H,  $7  (by  assumption  on  members  and  member,  since  op7  =  0), 
and  V(x,??,f)  G  E7  : 

■■  H';Ch  auth(%,  rj,  t)  and  H';Ch  auth \ 

•  The  converse  case  is  similar. 


Case  P  =  test  p  {P};  Q 

Then  P7  =  test  p  {P7};  Q'  such  that 
x  =  W(P), 

$  =  $,  pa, 

(cf,$,S)  hP^’x  P7, 

and  (a\x,  T,  S)  h  Q  H^4X  Q' . 

Furthermore,  let 

•  H'  =  H, 

S'  =  S , 

£'  =  £, 

07  =  0, 

and  Q  =  P;Q  such  that 
H  1=  pa. 

Then  Q'  =  P7;  Q7. 

We  require  (0,  $7,  E7)  h  Q  H-ikx  Q'  for  some  T7,  E7. 
Let  T7  =  $ 
and  E7  =  S. 
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By  Lemma  A. 3  and  weakening,  we  have  the  required  result. 

Finally,  we  have 
a  o'  where  jJ  =  /J, 

H'  1=  H ,  <h'  (by  assumption  above), 
and  V(x,?7,i)  G  S'  : 

::  H'\  C  h  auth(x,fot)  and  H'\  C  h  auth(x,foi)  \  £'(x,V,t)- 

•  H'  =  H, 

S'  =  S, 

e  =  z, 

a '  =  a, 

and  Q  =  Q  such  that 
H  \f  pa. 

Then  Q’  =  Q’ . 

We  require  (a,  <&',  S')  h  Q  H£>x  Q’  for  some  T'.  S'. 

Let  <!>'  =  $, 
and  S'  =  S. 

By  construction,  dom((j/)  n  (fv(T')  U  fv(S'))  =  0. 

So  the  required  result  follows  by  Lemma  A.l. 

Finally,  we  have 
a  <^/  a'  where  fj!  =  //, 

H'  1=  H,  $', 
and  V(x,??,t)  £  S'  : 

Z'{x,V,t)n'  ::  H'-C  h  auth(x,fot)  and  H'\L  h  auth(x,foi)  \  £'(x,V,t)- 

•  The  converse  case  is  similar. 


Case  P  =  (x  =  t;  Q ) 

Then  P'  =  (x  =  i;  Q')  such  that 

(<f[x  ta],  $,  5)hQ  Q'. 

Furthermore,  let 

•  H'  =  H, 

S'  =  S, 

?  =  £, 

a'  =  (7, 

and  Q  =  Q{t~c i lx}. 

Then  Q'  =  Q'{ta/x}. 

We  require  (a,  $',  S')  h  Q  H-&x  Q'  for  some  $',  S'. 
Let  $'  =  $, 
and  S'  =  S. 

By  Lemma  A. 2  we  have  the  required  result. 
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Finally,  we  have 
a  a'  where  jJ  =  fx, 

H’  1=  H , 

and  V(x,??,t)  G  S'  : 

s'(x,f7,*V  ::  I"  auth(x,  77,  t)  and  H'-£  h  auth(x,??,t)  \ 

•  The  converse  case  is  similar. 


Case  P  =  shell  n(p, . . . ,  t*,);  Q 

Then  P'  =  shell  n(t\, . . . ,  ifc);  Q'  such  that 

e  =  (A,c), 

A  (n)  =  771, 

(x,  77 i,Ua)  G  dom(S)  for  each  i, 

and  ((t,$,S)hQ  ^’x  Q7. 

Furthermore,  let 


•£'  =  £, 


<7  =  (J, 

and  Q  =  Q  such  that 

n(ticr,...,tkar) 

H,S  ►  H',S\ 

ZiXiVhtiP)  =  li  for  each  i, 

and  7j  ::  H;  C  h  auth(x,  r]i,ti<j )  for  each  2. 

(Note  that  we  have  H;  C  h  auth(x,  rji,  tier)  \  £(x,  r/j,  Ua)  for  each  i. 
So  by  Axiom  (5)  we  do  not  need  the  proof-checking  above.) 

Let  H(x,  iji,  ti<j )/i  =  7 j  for  each  i. 

By  assumption,  77  ::  H;  C  h  auth(x,  iji,  Ua )  for  each  i. 

Then  Q'  =  Q' . 

We  require  (cf,  <F,  S')  h  Q  Q'  for  some  <£',  S'. 


Let  <!>'  =  $, 
and  S'  =  H. 

Then  we  have  the  required  result. 

Finally,  we  have 
<7  <^/  <7r  where  fx'  =  /x, 

H'  1=  H,  •L'  (by  Axiom  (1)  and  assumption  on  <  and  l=), 
and  V(x,  ?7,  t)  G  S'  : 

S'(x,  V,  t)fj!  ■■  H'\ C  h  auth(x,  77,  t)  and  H'\  £  h  auth(x,  77,  t)  \  £'(x,  V,  *)• 


•  The  converse  case  is  similar. 


Case  P  =  assert  (77,  i);  Q  and  P'  =  {a  =  prove  (77,  t);  inject  (77,  i)  a;  Q') 
such  that  6  =  (_,  £), 
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[i]>  s? 


is  fresh, 

=  S[(x,7,to)  !-»•  a], 

(cf,$,S)bQ^xQb 
Furthermore,  let 

•  H’  =  H, 

S'  =  S, 

£'  =  £[(x,v,tc r)  7], 

o'  =  Ufa  1 — >  7], 
and  Q  =  Q  such  that 
H]  C  b  auth(x,  7,  ter)  \  7. 

Then  Q'  =  Q' . 

We  require  (cf,  <h7,  S')  b  Q  Q7  for  some  <h7,  S7. 

Let  <!>'  =  <f>, 
and  S'  =  H. 

Then  we  have  the  required  result. 

Finally,  we  have 

cf  <^/  o’  where  fx'  =  //[a  1— >  7], 

H'  1=  H,  <f>7, 
and  V(x,7,t)  G  S'  : 

S'(x,  V,  t)lJ  ■■  H'\ C  b  auth(x,  7,  t)  and  H'\  C  b  auth(x,  7,  t)  \  £7(x,  7,  *) 

(since  in  particular,  //';  £  b  auth(x,  7,  ter)  \  £7(x,  7,  to-) 

and  since  S'(x,  'Q.  to)n'  =  a/x'  =  7  =  £7(x,  7,  to), 

so,  by  Axiom  (5),  E' (x,r],to)ix'  ::  H'\C  b  auth(x,7>*))- 

•  H'  =  H, 

S'  =  S , 

o'  =  o, 

and  Q7  =  inject  (7,  t)  such  that 

b  auth(x,  7,  to)  \  7- 

Then  Q  =  P. 

We  require  (cf,  <h7,  S7)  b  Q  H-i>4x  Q'  for  some  <J>7,  S7. 

Let  <h7  =  $, 
and  E'  =  E. 

By  assumption,  we  already  have  H;  C  b  auth(x,  7,  to)  \  7. 

^  7T  0  \  " — " 

Now  we  require  (cf,  $,  S[(x,  7,  ter)  e- >  7])  b  Q  ~b  Q7. 

Since  a  ^  dom (cf),  the  result  follows  by  Lemma  A.l. 

Finally,  we  have 
cf  <^/  ex7  where  fx'  =  7, 

H'  1=  77,  <h7, 
and  V(x,7^)  £  -  : 
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■■■■  H';Ch  auth(x,  7,  t)  and  if7;  £  b  auth(x,7,0  \  g(x,V,t). 


Case  P  =  assert  (7,  t);  Q  and  P'  =  inject  (77,  t)  r,Q' 
such  that  6  =  (_,  £), 
if,  <I>;  £  h  |  “|  =t>  auth(x,  7,  ta)  \  7', 

7  =  V  (E>, 

S  =  hJ, 

and  h  Q  Q7. 

Furthermore,  let 

•  W  =  H, 

S'  =  S, 


and  Q  =  Q  such  that 
H;C\~  auth(x,  7 ,  ta)  \  7- 
Then  Q'  =  Q' 

and  £7  =  S.  __ 

We  require  (a,  <b7,  £7)  b  Q  H£>x  Q’  for  some  T'.  E7. 

Let  <!>'  =  $. 

Then  we  have  the  required  result. 

Finally,  we  have 
<7  <^/  er7  where  //  =  //, 
if7  i=  if,  4>7, 
and  V(x,  7;  t)  £  5'  : 

S'(x,  V,  t)fJ?  ■■■  if';  £  b  auth(x,  V,  t)  and  if7;  £  b  auth(x,  7,  t )  \  £7(x,  V,  t) 

(since  in  particular,  if7;  £  b  auth(x,  7,  ter)  \  £7(x,  7,  f cr) ,  and 

since  by  Axiom  (5),  7'  ::  ff;£  b  |S|  =7-  auth(x, 7, fer) , 

and  by  Axiom  (4),  (S)/x  ::  if;£  b  |E|, 

so  by  Axiom  (3),  77'  : :  if ;  £  b  auth(x,  7,  ta)). 

•  if7  =  ff, 

S7  =  5, 

£"  =  H/x[(x,7.^)  ^  7 M], 

a'  =  a, 
and  Q!  =  Q’ . 

Let  E7  =  S. 

Now,  by  assumption,  we  have  if;  £  b  | S|  =7  auth(x,  7,  ter)  \  7'. 

Also,  by  Axiom  (4),  we  have  (S)/x  ::  if;  £  b  |S|. 

So,  by  Axiom  (5),  7'  ::  ff;£  b  |S|  =7>  auth(x, 7,  ta). 

So,  by  Axiom  (3),  77'  : :  ff ;  £  b  auth(x,  7,  ta). 

So,  by  Axiom  (6),  if ;  £  b  auth(x,  7,  ta)  \  7  for  some  7. 
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Then  Q  =  Q 

and  £'  =  £[(x,??,h7)  ^  7].  _ 

We  require  (a,  $',2')  b  Q  H-&x  Q'  for  some 
Let  4>'  =  $. 

Then  we  have  the  required  result. 

Finally,  we  have 
it  <n'  o'  where  fj,'  =  p, 

H'  1=  H, 

and  V(x,foi)  G  S'  : 

S'(x,  V,  t)p'  ■■  H'\ £  b  auth(x,  V,  t)  and  H'\  £  b  auth(x,  V,  t)  \  £'(x,  V,  *) 

(since  in  particular,  FT';  £  b  auth(x,  77,  ter)  \  £'(x>  ??,  tu),  and 
7/x'  ::  i7;  £  b  auth(x,  rj,  to)  as  shown  above). 

□ 

Lemma  A. 5.  Lemma  A. 4  implies  Theorem  4-1. 

d  A* 

Proof.  By  induction  on  the  length  of  -A-  .  □ 

A. 2  Proof  of  Theorem  4.2 

The  proof  follows  by  observation  of  the  proof  of  Lemma  A. 4.  In  particular,  for  the  case 
where  P  is  a  shell  command,  using  the  relaxed  (Reduct  shell)  rule  suffices  to  establish 
the  required  invariants. 

B  Example:  Homework  for  Courses 

Consider  the  following  idealized  scenario  for  homework  management  of  various  courses  at 
an  university.  There  is  a  directory,  "/courses",  containing  the  directories  of  all  courses. 
In  each  course  directory,  there  is  a  directory  named  "instructor"  and  a  directory  named 
"students",  both  containing  directories  named  after  all  students.  Furthermore,  the 
"instructor"  directory  contains  a  file  called  "homework",  and  each  directory  under 
"students"  has  a  file  called  "solution". 

Figure  4  shows  a  PCAL  program  that  does  the  following.  It  navigates  into  the 
"instructor"  directory,  and  copies  the  "homework"  file  into  each  directory  under 
"students"  in  turn.  Then,  it  navigates  into  those  directories  and  copies  the  "solution" 
file  of  that  student  into  the  corresponding  directory  under  "instructor". 

Next,  we  show  the  policy  in  effect.  The  policy  is  written  in  the  authorization  logic 
BL  [15,  16].  In  order  to  represent  policies  made  by  different  principals,  BL  includes  a 
modality  A  says  s  which  means  that  administrator  A  states,  or  believes  formula  s  (s 
usually  expresses  a  policy  rule).  The  says  modality  has  been  considered  in  prior  work 
(e.g.,  [1,2,17,21]),  but  the  inference  rules  defining  its  meaning  vary.  BL’s  rules  are  shown 
below.  In  addition,  any  complete  axiomatization  of  first-order  intuitionistic  logic  is  also 
assumed. 
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/courses" ; 


1 

2 
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4 
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23 
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26 

27 

28 

29 
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32 

33 

34 

35 

36 


courses  = 

assert  (read,  courses) ; 
for  course  in  courses  { 
assert  (read,  course) ; 
for  user  in  course  { 

test  suffix  (user,  "instructor")  { 
instructor  =  user; 
assert  (read,  instructor); 
for  fileinstr  in  instructor  { 

test  suffix  (fileinstr,  "homework")  -( 
assert  (read,  fileinstr); 
students  =  course/"students" ; 
assert  (read,  students) ; 
for  studdir  in  students  { 

hwstud  =  studdir/ "homework" ; 
assert  (write,  hwstud); 
shell  cp  (fileinstr,  hwstud) 


> 


> 


>; 


{ 


test  suffix  (user,  "students") 
assert  (read,  user) ; 
for  userdir  in  user  { 

studname  =  base  (userdir) ; 

solninstr  =  course/"instructor"/studname/"solution" ; 

solnstud  =  userdir/"solution" ; 

assert  read  solnstud; 

assert  write  solninstr; 

shell  cp  (solnstud,  solninstr) 


} 


> 


Figure  4:  PCAL  program  for  homework  example 


h  ( A  says  (s  =k  t))  =k  ((A  says  s)  =k  ( A  says  t)) 

(K) 

h  s 

(N) 

f-  A  says  s 

h  (A  says  s)  =>  (. A '  says  A  says  s ) 

(I) 

h  A  says  ((A  says  s)  =>•  s) 

(C) 
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In  our  specific  policy,  we  assume  that  S  and  L  are  separate  authorities.  The  formula 
auth(Al,  77,  t)  is  defined  as  S  says  may  (A,  77,  t);  in  other  words,  S  represents  the  enforcer  of 
the  policy.  On  the  other  hand,  L  is  a  local  authority  that  may  certify  some  formulas  that 
S  relies  on,  for  example,  the  validity  of  the  "/courses"  directory  and  the  membership  of 
certain  principals  in  special  groups  for  which  certain  policy  rules  may  apply. 

We  focus  on  a  detailed  modeling  of  the  relationship  between  the  function  symbol  /  (that 
concatenates  directory  paths  with  file  names  to  to  give  file  paths)  and  directory  membership 
constraints.  This  allows  the  compiler  to  reason,  for  example,  that  if  /  is  in  directory  d  and 
the  suffix  of  /  is  x  then  /  =  d/x.  Other  rules  allow  principals  in  the  group  special  to 
inherit  read  permissions  from  ancestor  directories.  Finally,  there  are  rules  that  are  specific 
to  instructors  and  students,  specifying  which  files  in  the  others’  directories  they  are  allowed 
to  read  and  write. 

The  policy  rules  are  split  into  two  parts.  The  first  part  contains  the  rules  stated  by  L: 

Vc.  (S  says  member(c,  "/courses"))  =>  course(c) 

special("User") 

The  next  part  contains  the  rules  stated  by  S.  These  include  all  the  policy  rules,  plus 
rules  that  model  equivalences  between  paths  constructed  using  /,  base,  and  suffix. 


V/.Vd.Vr.  member(/,  d)  =>•  suffi x(f,x)  =$■  f  =  d/x 

V/.Vd.Vr.Vp.  member(/,  d)  =>•  suf  f  ix(/,  x)  =>•  d  =  p  =>•  /  =  p/x 

VAV/.Vp.V??.  /  =  p  =>•  may  (A,  77,  /)  =>•  may(^4,  rj,p) 

V/.  suf f ix(/,  base(x)) 

VAVc.Vd.  ( L  says  course(c))  =>•  may(yl, read, c/"instructor")  => 
may(^4,  read,  c/"students") 

A  member(ii,  c/"students")  =A  may(^4,  write,  (//"homework") 

VA.Vc.Vx.Vd.  ( L  says  course(c))  =A  may  (A,  read,  c/"students"/x)  =A 
may(yl,  write,  c/"instructor"/x/"solution") 

A  d  =  c/"students"/r)  may(^4,  read,  (//"solution") 

\/A.  may  [A,  read,  "/courses") 

VA.V/.Vd.  ( L  says  special(Al))  member(/,  d)  => 
may  (yl,  read,  d)  =>  may(yl,  read,  /) 

With  this  policy,  the  PCAL  compiler  can  eliminate  all  assert  statements  in  the  program 
of  Figure  4,  if  the  program  is  run  by  principal  "User". 
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